home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d20
/
lstcrc14.arc
/
LISTCRCS.HST
< prev
next >
Wrap
Text File
|
1991-09-11
|
6KB
|
115 lines
Revision history for LISTCRCS:
- I never thought such a simple utility would need a revision history,
which only goes to show how cocky I was. <GRIN> The next utility I
write *will* have a beta-testing phase...
- Version 1.0 (initial release): Advertised to Region 12 *EC's, Binkley
beta testers and QM beta testers. Initial motivation for problem was
a potential bug report by one NEC in Region 12 in the behavior of
Areafix.
- Version 1.1: Added detection and flagging of existing collisions
(translate: the tinkering bug bit me good...). Additional
distribution: Net 167 file sharing area, called QUEDIST.
- Version 1.2: Expanded the definition of "blank line"; the program now
treats as such not only true empty lines, but also lines starting with
a semicolon (";") or a dash ("-"). Thanks to a bug report from Bob
Davis (1:106/114), I was reminded that my habit of using truly blank
lines as visual separators was not as widespread as I first thought.
The QM documentation does, indeed, mention the semicolon as a comment
line flag. As for the dash, a remark by Raymond Beriau (1:167/305)
reminded me that ex ConfMail users may have brought such lines with
them. I now remember that *I* did keep such a line in my AREAS.BBS
file for a while when I first tried QM. Thank you Raymond!
Any other type of non-area, non-standard lines in your AREAS.BBS file
may still produce "interesting" output (as in the old Chinese curse:
"May you live in interesting times..." <grin>). I will let rule #1
of data processing, G.I.G.O. (if you don't know what it means, ask a
local friend), take care of such situations. As I believe I have now
accounted for all documented line formats, and one old inherited
(from ConfMail) format, (here goes: Open Mouth, Insert Foot... 8-), I
do not expect to have to fiddle much more with this. Unless I get
early problem reports from Bob, Raymond or anyone else to whom I
will now send this version, this is what will be released in the SDS
in a few days.
- Version 1.3: In the light of what the present paragraph says, you may
have a good chuckle when reading the rest of this file... If so, well
have a good one on me! This will only go to show that I am, after all,
very human, in that I can make the *dumbest* mistakes... It was just
brought to my attention that EchoMail area tag names are
case-insensitive (as if I didn't know it... ha!). It's just that I
made the fatal assumption that everyone would use all UPPERCASE
conference names in their AREAS.BBS file, but in fact there is no
obligation of doing this. My thanks to Jan Ceuleers of 2:295/53 for
pointing this out. This and some clarifications in my useless little
errorlevel-testing batch file are the only changes between versions
1.2 and 1.3.
- Version 1.4: 91/09/10 (Tuesday morning, in the "wee hours"... :-)
In the time-honored tradition of many other FidoNet utilities, I am
only documenting the changes for version 1.4 in this addendum rather
than redo the original documentation file, mostly because I don't have
a minute to spare, and I want to push this thing out the door and go
to sleep!
I wholeheartedly believed that the previous version (1.3) of this
utility would be the last to see the light of day before QM either
was fixed, or was made obsolete by some other program. Alas, this
was not to be! John Souvestre (1:391/1) recently came to me (via
NetMail... :-) with requests for additional features, both for
himself and on behalf of Tony Davis, our ZEC. As they were just
challenging enough for an evening of tinkering, I put them in,
and here they are:
- Two optional command-line parameters are now supported. The area
name to test is now the second one, with the first being the name
of the file containing the list of areas. That file name can also
contain a drive and/or path name, if so desired.
- If only a file name is supplied, version 1.4 will behave with it
exactly as 1.3 did with zero parameters, i.e. it will check all
areas listed in that file for a possible CRC collision, which
would guarantee a cross-link. If two parameters are supplied, the
second one is interpreted as the name of an EchoMail area that you
wish to create, and which is checked for cross-links against all
areas listed in the file referenced by the first parameter.
- If no parameters are supplied, the file defaults to "AREAS.BBS",
which must then reside in the current directory.
- An additional format is supported, in addition to AREAS.BBS for
QM and QECHO. The new format is popularly known, around these parts
anyway, as FIDONET.NA (where NA stands for "North America"), as this
is the name of the text-format forwarding list being used by the
North American EchoMail backbone to list all backbone areas.
- The logic by which the file format is identified now starts with an
examination of the first line of the file. If that line contains
the character '!' anywhere, the file is presumed (NO, I won't use
"ass-u-me-d"...! :-) to be some form of AREAS.BBS listing, and
further testing along that path is done, just as before, to
differentiate between the QM and QECHO formats. If no '!' is found
on that first line, the file is presumed to be in FIDONET.NA
format. Comments and area descriptions will be ignored if present in
a FIDONET.NA format file.
- The program's output is now split between the DOS standard output and
standard error streams. This provides the user with the ability to
produce a brief form of report by the simple expedient of redirecting
the standard output to NUL. What remains is then an abbreviated header,
and only CRC collisions are listed, while non-affected areas produce
no visible output. Now those people with the "too fast" computers, like
John and Tony <grin>, will be able to use LISTCRCS without fear of
missing important error messages as the output whizzes by on their
screens! :-)
- Hopefully, the HORRIBLE holes I had left on the errorlevel logic of
version 1.3 (but that nobody ever reported to me...) are now really
fixed!